…ws MAX_PATH

EngineManager.get_engine_path encoded every UNet build flag verbatim into the
on-disk directory name. With a realistic engine_dir (fp8 + static batch +
pin_cache_frames + optlvl + resolution), the folder grew to 246 chars, and the
derived unet.engine.onnx / unet.engine.opt.onnx paths hit 263/267 chars --
over Windows' 260-char MAX_PATH. Because the *directory* fit but the *file*
didn't, mkdir succeeded while torch.onnx.export's open(onnx_path, "wb") raised
FileNotFoundError, which wrapper.py's OOM-only fallback doesn't catch, so the
build failed with "Acceleration has failed: [Errno 2] No such file or
directory: ...unet.engine.onnx".

Fix: for EngineType.UNET only, hash the fully-assembled flag prefix (sha1,
first 12 hex chars) using the existing _lora_signature hashing idiom, keeping
model name + fp8 + resolution human-readable in the folder name. Cache-key
precision is unchanged (identical configs still hash identically, differing
configs still diverge) -- only the on-disk encoding is compacted, from ~267
chars down to ~132. VAE/ControlNet directory naming is untouched, so existing
VAE engines are not invalidated; UNet engines rebuild once under their new
hashed folder name. Also adds a belt-and-suspenders warning if a derived path
would still approach MAX_PATH (e.g. an unusually deep user engine_dir), and
casts the "filename" config lookup to str to keep the type checker precise
about self._configs' heterogeneous per-key value types.

Adds a regression test (test_engine_path_length.py) that reproduces the exact
crash-log config and asserts the derived .onnx / .opt.onnx paths stay under
MAX_PATH, plus determinism and no-collision checks.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

… gate (see #11)